1. Field of the Invention
The present invention relates to the field of computer software and, more particularly, to enhancing the presentation of help messages in interactive voice response (IVR) systems.
2. Description of the Related Art
Interactive voice response (IVR) systems can provide human/computer interfaces included in a variety of applications, such as customer relation management systems, automated survey applications, telemarketing applications, customer service kiosks, and the like. IVR systems can audibly present a series of user selectable options and can responsively receive user input in the form of a speech input, a touch tone-keypad selection, and other such responses. Depending upon a user's selection, the IVR system can audibly present additional options, can audibly play an informational message, can initiate an automated action like a bill payment action, and/or can transfer a customer to a human agent.
IVR systems commonly present numerous help messages responsive to user initiated help requests and/or system initiated help requests. A user initiated help request refers to a request where an IVR user explicitly selects an IVR help option. A system initiated help request can result from a variety of system events such as a time-out event, where no input is received for an established duration, and a no-match event, where input cannot be matched to a valid IVR option.
A requested help instance can result in a help dialog state being initiated for resolving the problem indicated within the help request, where a dialog state is an IVR branch for handling a specified problem. Commonly, one or more sets of help messages can be associated with the dialog state. The set of IVR help messages can be arranged in a variety of levels of increasing descriptive content and/or according to an established hierarchy of content. For example, a first-level help message can include short phases providing context-sensitive help information. These short phrases can describe the available help options and corresponding keypad and/or voice commands necessary to select a desired option. A second-level help message can present the same help information as the first-level help message, yet provide more comprehensive explanations for the menu options or input actions. Alternatively, a second-level help message can be a further decomposition of one option presented within the first-level help message. It should be noted that generally the greater number of distinct messages and/or menus provided within an IVR system, the more expensive it becomes to maintain and develop the IVR system. Accordingly, it can be preferable to implement as few help messages as possible to achieve a desired functionality, while simultaneously implementing a sufficient number of help messages to achieve the desired usability.
Most current systems provide users with some help or re-prompting when a user explicitly requests help (through speech or keypad), provides no input, or provides an input resulting in a no-match event. One current solution is to treat explicit requests for help, no-input events, and no-match events equally. For example, responsive to a first help initiating event, the IVR can present users with a small amount of context-sensitive help information, such as a first-level help message. Responsive to a second help initiating event, the IVR can present users with additional help information, such as a second-level help message. The IVR can include any number of help levels that can be presented in this fashion. At some point in the help process, a user can be transferred to a live call agent, can be transferred to a dual-toned multi-frequency (DTMF) version of an application, and/or can be cycled through the help levels.
While the conventional IVR help implementation method is generally successful for system initiated help requests, it is only partially successful for users who explicitly request help. More specifically, the above detailed help method is generally adequate for users that need only a small amount of context-sensitive help, such as a first-level of help. Other users, however, who explicitly request help are often interested in hearing all help that is available for the dialog state for which help was requested. Systems requiring users to request “help” from within the first-level message can be highly confusing to users. Appreciably, it can be unintuitive for users to request “help” again after having requested “help” a first time.
A second conventional solution is to provide users who explicitly request help with all the help information available at a given point in the dialog, but to provide help resulting from a system initiated help request with short, context-sensitive help. The second conventional solution penalizes help requesters who need only the short context-sensitive help. Even when systems permit barge in, many users prefer not to barge in (interrupt a system message) for fear of missing an important message and, in speech recognition systems, to conform with the typical social protocols of conversation. Accordingly, users that explicitly initiated help can be required to listen to additional, unnecessary information. Further, users who receive system initiated help can often (unhelpfully) hear the same help information twice in a row due to commonly utilized branching mechanisms. In light of the above-mentioned problems associated with current methods for providing IVR help, one can appreciate that a method of providing IVR help that does not confuse users, that adequately addresses the help requirements of all IVR users, and that does not significantly increase IVR overhead, is needed.